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Abstract — In this work we describe the PriSM framework for 
decentralized deployment of a federation of autonomous social 
networks (ASN). The individual ASNs are centrally managed 
by organizations according to their institutional needs, while 
cross- ASN interactions are facilitated subject to security and 
confidentiality requirements specified by administrators and 
users of the ASNs. Such decentralized deployment, possibly either 
on private or public clouds, provides control and ownership 
of information/flow to individual organizations. Lack of such 
complete control (if third party online social networking services 
were to be used) has so far been a great barrier in taking full 
advantage of the novel communication mechanisms at workplace 
that have however become commonplace for personal usage with 
the advent of Web 2.0 platforms and online social networks. 
PriSM provides a practical solution for organizations to harness 
the advantages of online social networking both in intra/inter- 
organizational settings without sacrificing autonomy, security and 
confidentiality needs. 

Index Terms — online social networking platform; decentraliza- 
tion; federation; autonomy; private/public cloud; workplace 

I. Introduction 

Online social networking and other Web 2.0 applications 
have brought in a paradigm shift in the manner in which people 
communicate and interact online. Realizing the versatility, 
flexibility and reach of open online social networks such as 
Facebook and Twitter, they have been widely embraced by 
organizations for public relations as well as marketing and 
monitoring purposes. Some relevant Web 2.0 technologies, 
such as Wikis are also readily deployed within corporate 
Intranets. However, other platforms, particularly social net- 
working, despite its preponderance in the Internet setting, are 
yet to become an integral part of individual organizations' 
internal communication and workflow infrastructure. 

While the new modes and (more importantly) opportunities 
of interaction that social networking platforms provide can 
significantly help improve an organization's internal dynamics, 
there have so far been several barriers in wide- scale adaption 
of such infrastructure in workplace. Foremost, a Facebook like 
platform which is open to all, and hosted and controlled by a 
third party is unsuitable for storing and communicating sensi- 
tive business data and information. In contrast to Wiki-engines 
which can be privately deployed, there has been a relative lack 
of out-of-the-box social networking platform software Q Fur- 

1 We note that recent implementations arising from works on decentralized 
online social networks are partially filling up the void. 



thermore, each organization is differently structure, and carries 
out distinct activities, thus it is essential to be able to map 
these organizational structures and processes in the platform. 
Ultimately, even if most of the interactions are carried out 
within corporate boundaries, ability to interact with outside 
entities, for example, with customers or suppliers (or even 
across different departments or project groups within same 
organization), requires mechanisms enabling easy and flexible 
ways to express rules of engagements and enforce and monitor 
the same subject to various security and confidentiality needs 
of the stake-holders. 

In this paper we present a framework for deploying au- 
tonomous social networks (ASNs) that can be run and ad- 
ministered independently, and can further be federated with 
other ASNs trough trusted peering links. PriSM (Private Social 
Mesh) implements such a framework. This results in a hybrid 
architecture, where individual ASNs follow traditional OSN's 
client-server model, while the federation is achieved in a peer- 
to-peer manner. 

An analogy for such decentralized social networking plat- 
form deployment may readily be drawn from the way 'emails' 
work. Individual organizations often choose to run their own 
private email servers catering to their users, while these users 
can also communicate with users using other email services. 
Furthermore, organizations may also choose to rent the server 
functionalities or even the whole email service from a cloud 
based service provider. Our PriSM implementation allows 
similar deployment models, i.e. deployed from scratch on 
personal servers/private clouds or on a public cloud service 
providing Infrastructure as a Service (IaaS), or alternatively, 
get administrative access to a preinstalled, akin to Software as 
a Service (SaaS). However, in contrast to email's any-to-any 
communication paradigm, PriSM allows ASN administrators 
as well as an user's superiors from within the organizational 
hierarchy to determine intra/inter ASN communication restric- 
tions. 

The main contributions of this work are as follows: (i) 
A framework for decentralized deployment of autonomous 
social networks (ASNs) which allow their users to map their 
respective organizational structures and processes such as 
departments, project (sub-)groups, etc. is proposed, (ii) The 
proposed framework supports federation of ASNs with peering 
mechanisms for inter- ASN user interactions, (iii) It allows 



to scope intra/inter-ASN interactions flexibly, determined by 
users (and their superiors) subject to business as well as 
individual privacy and confidentiality needs. Furthermore, the 
decentralized architecture naturally allows for deployment of 
individual ASNs in both private/public server/cloud environ- 
ments. 

The rest of the paper describes the model and implementa- 
tion of the PriSM framework as follows: Section UTI describes 
the network model while Section [TTT] describe the "frontier" 
information propagation & control mechanism. In Section IV 
we present the access control mechanism deployed in PriSM 
and Section [V] presents the architecture of the framework 
detailing encountered implementation issues and summarizing 
lessons learnt from the experience. Relevant related works are 
discussed in Section IvH We draw our conclusions and outline 



our ongoing and planned extensions of PriSM in Section VII 



II. The social mesh model 

We define a social mesh as a network of social networks, de- 
scribed next by borrowing some terminologies from sociology 
literature Q. Naturally, the model is rather standard besides 
the different typology of groups provided. But before going 
into the definition of the model, let us briefly and informally 
describe these groups types, why they are required by the 
presented model. Figure [T] shows a simple example instance 
of a Social Mesh. 




ASM ASN2 

Fig. 1: The social mesh model. 

A. Informal introduction to the concepts. 

As briefly mentioned in Section [TJ PriSM models what we 
call a Social Mesh, which is a network interconnecting distinct 
Autonomous Social Networks (or ASN for short). An ASN is a 
communication channel officially used by an organization and 
which materialize the structure of the organization. Moreover, 
ASN must reflect both the organization's policies in terms of 
information flow and permissions of the users. In what follows 
we assume that a user is employed only in an organization. 
Hence, in our model, an individual with multiple accounts 
across different ASNs is considered as distinct users. 

The information flow across different users of an ASN 
and across different ASNs is managed by means of circles. 
Namely, a circle is a group of users of the social mesh and an 
associated set of rules controlling how information - messages 



- associated to such circle can be accessed by users not 
belonging to the circle itself. 

Different types of circles are required in order to represent 
the different types of users' groups which may exist within 
an organization. Because of that, we need circles representing 
both the internal structure of complex organizations as well 
as other circles not directly mapping formal structure of an 
organization. We call circles materializing structures of an 
organization as subdomains. Example of subdomains may be 
departments of a university or branches of a company. 

On the other hand, circles representing groups created for 
official purposes, but without a direct mapping into the orga- 
nization's structure, are called public groups. As an example, 
a public group may be a team of users working on a specific 
project. The project itself may be handled by users belonging 
to different departments of the company such as developer 
from the IT Department (a subdomain) and users from Sales 
Department (another subdomain). Hence, the main feature 
characterizing a public group is the purpose for which it has 
been created. Some ASNs may allow users to create and join 
public groups created for purposes not directly work-related 
such as a group created to simplify the communication among 
the players of the IT Department Soccer Team. As opposed to 
subdomain, members of a public group may belong to different 
ASNs, such as a research project carried out by researchers 
and professors from different universities. 

Moreover, PriSM allows users to define personalized circles 
called private groups in which users are categorized according 
to the preferences of the creator of the circle. Such private 
groups are strictly private to the creator of the circle, and 
thus unknown to the users who are categorized. Private groups 
provide a tool to control the flow of an individual's messages in 
a fine-grained manner (akin to the use of circles in Google+), 
for example specifying that a message is visible only to the 
user categorized to a specific private circle. As a more "con- 
crete" example, consider a researcher working on a project 
crucial for the company. She/he may create a private group 
of "untrusted colleagues" to avoid such users from receiving 
messages exchanged within the research team. 

Beside information flow, ASNs require a way to manage 
the privileges of their members. In the following we define as 
privileges the operations that a user is allowed to perform in a 
ASN. To do that PriSM uses an approach similar to |2|. PriSM 
uses the roles assigned to user by the ASN administrator. 
In the presented model a role is a job function/title within 
the organization with some associated semantics regarding the 
authority and responsibility conferred on a member role. We 
assume that a user may be associated with multiple roles, 
according to the functions she/he is performing within the 
organization. Furthermore, PriSM allows the administrator to 
further refine the privileges available to a given user according 
to "where" she/he is operating. In fact the privileges granted 
to a given user at a given moment are defined combining the 
roles to which the user has been assigned and the subdomain 
in which she/he is operating. Thus, the subdomains contribute 
to identify the available privileges, refining the privileges of 



a role (both granting or revoking privileges) or even grant- 
ing/revoking permissions directly to specific users. 

Beside that, a group creator may be interested into restrict- 
ing the membership to the group, for example not granting 
the membership to those users who are member of another 
specific group. Moreover, one may be willing to moderate the 
messages associated with a given group. PriSM provides to 
the users the possibility to specify group privileges (to be 



explained in Section [TV|). 

Table |l| summarizes the characteristics of the groups dis- 
cussed so far. Namely, it shows the properties of the different 
user groups defined in the PriSM's social mesh model. 
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TABLE I: Different type of user groupings and their charac- 
teristics. 



B. A more formal definition of the model 

We will now formally define the components of the PriSM 
social mesh model. 

Definition 2.1 (Social Mesh): A Social Mesh SM is a tuple 
(ASM,U, 'PGi ) where ASM is the set of autonomous social 
networks, hi is the set of users. Each user u G U belongs to 
exactly one autonomous social netowk asn G ASM. Finally, 
VQ is the set of public groups defined in SM. 

Informally, a Social Mesh is a network of users partitioned 
into distinct and non-overlapping autonomous social networks. 

Definition 2.2 (Autonomous Social Network): Given a so- 
cial mesh SM, an autonomous social network asn G 
ASM(SM) is a tuple of the form (a, UV, SV, rsd, 1Z) where 
UV C U(SM) is the set of users of asn and a G UV is the 
administrator of the autonomous social network. Moreover, 
SV is the set of subdomains defined in asn, rsd G SV is the 
main subdomain and 1Z is the set of roles defined in asn. 

As mentioned in Section |II-A[ an autonomous social net- 
work represents an organization which is operating into the 
SM in order to allow its members to exchange informa- 
tion with others. Given an autonomous social network asn, 
rsd(asn^ denotes the main subdomain of asn. We define 
main subdomain as the domain corresponding to the organi- 
zation represented by asn. Therefore, a user u G UV(asn) iif 
u G M {rsd(asn)^ 

Definition 2.3 (Role): Given an autonomous social network 
asn G ASM, a role r G IZ(asn) is a tuple of the form 
(n, VIZ) where n is the (unique) identifier of the role and VIZ 
is the set of privileges granted and/or denied to the members 
of the role r. 

As previously mentioned, roles defines the privileges as- 
signed to the users belonging to them. Note that we assume 

2 We use the no tatio n E(T) to denote the element E of the tuple T. 
3 See Definition 2.5 



n(r) to be unique within each autonomous social network. 
Moreover, roles may be organized hierarchically. 

Definition 2.4 (Role hierarchy): Let 1Z be a set of roles de- 
fined for an autonomous social network asn. A role hierarchy 

<l)n ' 1Z -> 1Z U {±} 

is the function which defines the child-parent relationship 
among the roles. 

The definition of the hierarchy among the roles is mandated 
to the autonomous social network's administrator a(asn). Note 
that, given a role r G 1Z, <fin( r ) = -L if and only if r has no 
parent role. 

Definition 2.5 (Subdomain): Given a social mesh SM 
and an autonomous social network asn G ASM(SM), 
a subdomain sd G SV(asn) is a tuple of the form 
(n, M,T1Z,T ,a, f) where n is the identifier of the subdo- 
main, M C UD(asn) is the set of members of sd, VIZ is the 
set of privileges granted by the administrator to the members 
of the subdomain sd, V is the set of rules defining the con- 
straints a user must satisfy in order to access messages tagged 
with sd (or any circles children of sd, see Definition |2.6| 

2.10|) and a G M(sd) is the 



Definition 



2.8 



and Definition 



administrator of sd. 

Subdomains are characterized by users and administrator 
and, as introduced in Section |II-A| by rules and privileges. 
Contrary to autonomous social networks subdomains may be 
intersecting. 

Example 1: As an example, consider a user u belonging 
to the autonomous social network University a- Let u be 
a professor of the School of Computer Engineering (a sub- 
domain) but she/he is also member of the UniversityB (a 
different subdomain organizationally unrelated to the School 
of Computer Engineering). 

Similarly to roles, subdomains may be organized hierarchi- 
cally. 

Definition 2.6 (Subdomain hierarchy): Let SV be the set of 
subdomains defined for an autonomous social network asn. 
The subdomain hierarchy 

<j>sv : SV -> SV U {±} 

is the function defining the hierarchy among the subdomains. 
Note that 3! sd G SV such that <j>sv(sd) = _L 

Note that we define that the only subdomain allowed to 
have an undefined parent is the root domain. More formally, 
given an autonomous social network asn and given a sub- 
domain sd G SV(asn), (j)sv(asn)( s d) = _L if and only if 
sd = rsd(asn). 

Definition 2.7 (Public Group): Given a social mesh SM, 
a public group PG G VQ(SM) is a tuple of the form 
(o, M,B,V) where o eU is the user who created the public 
group, M C hi is the set of users who are member of c. 
B C M is the set of "bosses" of c, i.e. the users who can 
modify V, the set of rules associated to the public group. 

A user u is allowed to create public groups within a social 
mesh SM only if the autonomous social network to which 
she/he is member grants her/him such privilege. 



Definition 2.8 (Public Group hierarchy): Let VQ be the set 
of public groups and let SV be the set of subdomains of a 
social mesh SM. The public group hierarchy 

<hg -vg -^vgusvu {±} 

is the function defining the parent-child relationship for public 
groups. 

Note that according to Definition |2.8| a public group may 



be child of subdomain. The opposite is not true as stated in 
Definition 12.61 

Definition 2.9 (Private Group): Given a user u, sl private 
circle prg £ VlZQ{u) is a tuple of the form (M,,V) where 
M. C U is the set of users who are member of prg. V is the 
set of rules associated to the private group. 

A private group is a group of users defined by another user 
for a practical purpose: fine-grained manage information flow 
with respect to some, well identified, users. As per subdomains 
and public groups, private groups can be organized in a 
hierarchy to simplify their management. 

Definition 2.10 (Private Group hierarchy): Let VlZQ{u) 
be the set of private gropus for a given user u. The private 
group hierarchy 

4>vng - vng(u) -+ vng(u) u {±} 

is a function defining the child-parent relationship among the 
private groups of u. 



Note that according to Definition |2.10| private groups are 
personal. Thus, a private group may inherit only from another 
private group of the same user. 

Because subdomains, public groups and private groups are 
used to define who is entitled to access a specific message, 
we refer generally to all such entities as circles. 

Definition 2.11 (Circle): Give a social mesh SM the set of 
circles C is defined as follows: 

C = VG(SM) (J SV(asn) (J VKQ{u) 

asneASM{SM) ueU(SM) 

Even if all the previously mentioned groups are circles, it 
is useful to identify the available circles of a given user u. 

Definition 2.12 (Available Circle): Given a social mesh 
SM and a user u £ U{SM), the set of circles available to u 
is defined as: 



C{u) = Vg(SM) 



u 



SV(asn) U VKG{u) 



%eASM{SM) 



In the following we will use the terms circle and available 
circle interchangeably. 

As mentioned in Definition |2J) information flow restrictions 
are defined using rules 1Z, which will be better described in 
Section [Inl 

Definition 2.13 (User): Given a social mesh SM and an 
autonomous social network asn £ ASAf(SM), a user u £ 
UV(asn) - which we remind is a subset of U(SM) - is a 
tuple (n^T^lZ^VlZg) where n is the name (id) of the user, 
T C U(SM) is the set of users whose messages u is interested 



in, 1Z C TZ(asn) is the set of roles associated to u and VTZQ 
is the set of private groups defined by u. 

Informally, a user u is a person operating in the social 
mesh SM. The name n(u) has to be unique within SM 
and, because of that, within the ASN to which she/he is 
membei^] Moreover, the set F{u) defines the relationship 
existing between the user u and other users of SM. According 
to this model the relationships connecting two users u, v 
are oriented, v £ F{u) does not imply that u £ F(v). 
For instance a person may want to keep track of all updates 
from his boss regarding a project, but the boss may not want 
updates for every communication among the project members. 
In Figure [T] the oriented arrows represent the subscriptions 
existing among the users. The bi-directional arrows represent 
mutual/reciprocative subscriptions. This differs from the usual 
definition of relationship in social network, such as the ones 
represented in popular online social networks like Facebook, 
but it has many real life examples, and is also used in other 
social media such as Twitter. Note that a user u get update 
notifications based on a publish/subscribe model, where T 
represents an user's subscriptions. This is besides messages 
some users may explicitly send to u. 

Example 2: As an example, consider the social network of 
a school, created to provide an e-learning services. The teacher 
will be interested in the messages generated from the dean of 
the school. On the other hand the students will be interested in 
the messages from the teachers while the teachers may not be 
interested in receiving messages from all the students enrolled 
to a class. 



For simplification of exposition, Definition |2.13| specifies 
a single "type" of relationship. However different relationship 
types as specified in [ 3 ] can be incorporated in PriSM to reflect 
the semantics of the relationships. 

Definition 2.14 (Message): A message m is a tuple 
(u^t^Tjl) where u £ U is the author of the message, t is 
the content. T,IC C(u) are respectively called the tag and 
the conflict set. 

Informally we identify as a message m any information - 
collaborative documents, files, etc - created and distributed 
within the PriSM mesh. As stated in Definition |2.14| a 
message m is associated with two sets of circle^] The tag 
set T(m) identifies the context within which the content has 
been created, and according to which it should be propagated 
within the social mesh. On the other hand, the conflict set 
X(m) identifies the set of circles which are in conflict with 
the current content. In other words, the conflict set is a way 
to identify the set of users to whom the message should 
not be propagated. Both the tag and conflict sets are used 
in conjunction with the enforcement of propagation rules 
associated with a circle. 



4 We remind that a we are assume that a user operating in multiple ASNs 
is identified by m ultiple accounts, one per ASN. 



5 See Definition 2.11 



III. Frontier Information Propagation Mechanism 

The Frontier Information Propagation Mechanism ensures 
that a given message m is accessible by all the users who 
are member of at least a circle in T(m) but who are not 
member of any circle in T(m). In addition, other users may 
read the message m satisfying the policies of at least a circle 
c G T(m). Moreover, it is also possible for a user to access 
m if there exists a sequence of circles CSeq = ci, . . . ,c n 
where c n G T(ra) and Vi G [2,ti],0(q) = Ci-i- The user 
u is allowed to access m if and only if she/he satisfies the 
policies defined for all the circles in CSeq. 

The syntax and enforcement of policies is outside the scope 
of this work and treated in works such as [4]. Informally, 
policies are of the form: a <— predi A ... A predk where 
a G {allow, deny} and each predicate predi verifies 
properties of the message, the author of the message or 
the user reading the message. The properties verified by the 
predicates currently supported by the framework comprehend: 
author/reader identity, author/reader membership, tags of the 
message etc. The enforcement mechanism is described in 
Alg.0 

Input: m, the message to be accessed, u the reader of 
the message 

begin 

for c G T(m) do 

if u G M(c) then 
L return deny; 

for c G T(ra) do 
c':=c; 

while c' ^ JL do 

if ueM(d) then 
| return allow; 
else 

if verifies (u, V(c')) then 

L C := <Xc'); 

return deny; 

Algorithm 1: The Frontier Information Propagation Mecha- 
nism. 

Consider an example scenario shown in Figure [2] In such 
scenario the users Bob, Charlie and Ellen are following Alice. 
Alice is member of the circle C\ which is in turn an inner 
circle of Ci- Suppose Alice creates a message m such that 
T(m) = {Ci} and that Z(m) = 0. As previously defined, 
the Frontier Information Propagation mechanism states that if 
3c G T(m) such that reader G M(c) then reader is allowed 
to access the message. Thus Bob is allowed to access m since 
he is a member of C\. On the other hand the other users 
will satisfy the policies of C\ to access m. Supposing that 
both Charlie and Elen satisfy such policies, only Charlie will 
access m because he is a member of C2. Hence, Elen will be 
required to satisfy also the policies of C2 before being able to 



read content from the circle C2. 

If the collision set X(m) is not empty, then it is verified if 
the reader is member of any of the circles in such set. If this 
is the case then the reader is not allowed to access m. 



Elen _ _ C 2 

v Charlie 




Fig. 2: An example for the frontier information propagation 
mechanism. 



IV. Privileges' Management 

PriSM supports what we call group and domain privileges. 
The former are those privileges defining the actions users can 
perform within a group, such as the privileges of joining the 
group, to tag a message with the current group or the require- 
ment of the messages tagged with a group to be moderated by 
a boss of the group. The latter are those privileges granting to 
users administrative powers, such as the privileges to create 
public circles, to create subdomains, to create roles and so on 
and so forth. 

Group privileges are specific for the defining group to which 
are defined and therefore their enforcement is straightforward: 
once a user is operating in a specific group, the group 
privileges are applied. 

Differently, domain privileges require a more complex 
mechanism to be enforced. Note that the PriSM framework 
manages and enforces access control at ASN's level, in the 
sense that the domain privileges are defined in groups char- 
acteristics of a ASN - such are roles and subdomains - and 
they can be enforced only within the specific ASN. 

As introduced in Section III-AI and formalized in See- 
the operations a user is granted to perform are 



II-B 



tion 

defined by a combination of her/his roles and the subdomain 
in which she/he is operating. Because of that, the PriSM 
framework enforces access control differently according to the 
action performed by the user. 

The enforcement algorithm works as follows. Let us assume 
a given ASN asn and the user u G U(asn) who is associated 
with the roles n, . . . ,r n G TZ(asd). Thus, u is granted the 
privileges u-pn = UlLi VHfc). When u operates within a 
subdomain sd G SV(asn) the privileges actually granted to 
u are computed as: 

u vn <g> VlZ(sd) 

The predicate (g) refines the privileges in u-p-jz with the ones 
defined in V7Z(sd) - see Figure [3] With refine we mean that 
the privileges defined for sd may both extend, granting new 
privileges, or restrict, revoking existing ones, the privileges in 

v>vn> 
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Fig. 3: Access control model. 



V. PriSM architecture 



In order to provide the services required by an ASN each 
domain deploys PriSM locally. Figure]?] shows the architecture 
of an independent ASN deployment comprising several inter- 
connected modules. Each module is in charge of managing 
a specific subset of the features provided by the system. 
Many of these features are 'standard' in any state-of-the-art 
online social network platform while a few others are novel, 
specific to PriSM 's distributed/federated nature and its access 
and information flow controls: 

• User Manager: This module provides an interface to the 
operations directly related to the users, such as registra- 
tion, profile management, relations and subscription of 
messages from other users, etc. 

• Circle Manager: This component controls the circles 
related information such as the lists of members and 
the propagation policies for each circle other than any 



relationships between them (See Definition 2.6 and Def- 
inition |2lU] ). 

• Access Control Manager: This module regulates both 
the actions performed by the users of a PriSM ASN with 
respect to the privileges assigned to them by the domains 
administrators and enforces the policies defined in the 
circles (the later is elaborated in Section ]V-A| ). 

The functionalities of this module are: (i) to store and 
propagate the messages (and content) generated by the 
ASN's users and (ii) to grant access only to those users 
who are allowed according to the rules. 
The PriSM Web Interface exposes the services orchestrated 
by all these constituent modules to the ASN users. A final 
module manages the interconnections between the different 
ASN instances of PriSM. 

• Remote Interface: This module is in charge of perform- 
ing the operations of exchanging information with other 
ASNs. For example, the Remote Interface retrieves the 
required data when a user is accessing the profile of 
some user u' in some other domain D' . It also sends to 
the interested domains the updates involving shared data, 
such as those regarding the members and/or the policies 
of shared circles. 



The present PriSM implementation allows communica- 
tion between only ASNs which have been manually 
paired by the domains' administrators. Paired ASNs are 
considered trusted in the current model. Additionally, at 
present we assume the existence of a service to correctly 
discover other ASNs and their trustworthiness. These 
assumptions need further consideration in future. We will 
also like to note that individual ASN deployments are 
free to tweak the constituent modules, to add or modify 
functionalities as deemed appropriate. 
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Fig. 4: PriSM ASN architecture. 



A. Message propagation 

The primary objective of the PriSM system is to allow 
users to exchange information. In order to provide to the 
users with satisfying experience, the architecture of PriSM has 
been designed to reduce the time elapsing between when the 
information is created and when it is actually available to the 
final user. 

Figure [5] shows the steps required to post a message 
through the system to all the users potentially interested 
in it. First of all the user u sends the message m to the 
Content Manager (1), which stores the message in the local 
database. Afterwards, the Content Manager retrieves the set 
of followers T = {ui, . . . ,Uk} from the User Manager (2). 
The Content Manager requests to the Access Control Manager 
for each local user U{ G C C P, if m is allowed to 
access m (3). The verification is performed by Access Control 
Manager according to both the tag set, the conflict set(see 



Definition 2.14), the set of circles to which u[ is member and 
the list of propagation polices. Such information are retrieved 
by the Access Control Manager querying the Circle Manager 
(4). If the verification (3) holds then the Content Manager will 
notify the user Ui, immediately if the user is currently online 
or delivered in the user's 'inbox' to be retrieved as soon as 
she/he logs into the system (9). At the same time, the Content 
Manager sends the set of remote users VIA — T \ C to the 
Remote Interface (6) which will, in turn, extract the set of 
domains VSD = {di, . . . ,d q }, with q < \1ZU\, to be notified 
of the existence of m (6). 



The action of notifying the remote domains actually consists 
in forwarding m. Therefore, each remote domain rd G 7ZV 
will send the message m to the local Content Manager (8) 
which, in turn, will perform the steps (2) to (4), as performed 
by the Content Manager of the original domain, including the 
final notification (9) to the users local to rd. 

We assume each domain to be trusted. It means that the 
Access Control Manager will behave consistently across all 
ASNs. Moreover, we assume that circles' data and messages 
will be replicated among different domains, mainly to reduce 
the latency of the system. Note that such an assumptions do not 
introduce any vulnerability substantially different than while 
using other modes of electronic communication such as email. 
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Fig. 5: How to post/retrieve a message in PriSM. 

B. Implementation of the framework 

The model described in Section [TT] and the architecture pre- 
viously presented have been implemented in a prototype using 
Java 6 and GWT^Jfor the user interface. A MySQLQ database 
is used for the persistency of the data. The communication 
protocol between the different deployed ASN instances occurs 
using a well defined REST interface 13. 

The current prototype is structured as a modular server, in 
which each component is directly connected with the others 
as shown in Figure [4] Nevertheless, the server modules can 
be easily separated on different machines, to take advantage 
of such parallelism. 

A final remark we will like to make, to repeat what has 
been stated elsewhere, is that the individual modules can be 
modified, or additional modules added, as deemed essential for 
an ASN instance. Furthermore, we are working on exposing a 
set of interfaces so that other "apps" can be deployed on top 
of PriSM by leveraging on its existing functionalities. 

C. Evaluation and discussion of the architecture 

From our observation the PriSM architecture presents 
mainly three possible scalability bottlenecks (i) the Web 
Interface (ii) the Remote Interface and (iii) the database. 
More precisely, increasing the number of the users of a ASN 
increases the probability of users connected simultaneously 
to the system. Such condition will require an ever increasing 

6 http: //code.google.com/webtoolkit/ 

7 http : //w w w. my sql .com/ products/community 



amount of computational resources. Similarly, more resources 
are required to provide the same promptness of the system at 
the increase of the number of interconnected ASNs. 

The three previously mentioned issues can be addressed 
using standard distributed systems techniques, such as replicat- 
ing the appropriate modules of the architecture. Each module 
of the PriSM 's architecture is stateles^] and internally highly 
parallelized precisely with the intent to simplify its replication. 
Similarly, the database it can be replicated and distributed as 
well. However, such operation will have a cost in term of an 
increased complexity to manage the consistency of the data. 

We benchmarked the performances of the remote operations 
to empirically verify the scalability of the proposed architec- 
ture. We evaluated the execution time of each remote operation 
varying the number of involved ASNs. The experiments have 
been executed in a network of two computers (Linux 3.0.1 
running on a Intel Core 2 Duo 2.53GHz with 4GB of RAM). 
On the first machine we ran the PriSM prototype while on 
the other machine ran a 'light weight' version, which do not 
provides the Web Interface. The results are shown in Figure [6] 
As one may notice, the time required for the execution of 
each operation is negligible except for sending messages to 
the remote ASNs - the Post operation. We observed that 
PriSM prototype requires on an average 8780 milliseconds 
to propagate a message to 250 distinct ASNs. 
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Fig. 6: Empirical evaluation of the architecture's scalability, 
the y-axis uses a logarithmic scale. 

Finally, we benchmarked the time required for a user to 
access a given message. In particular we evaluated two aspects: 
the length of the sequence of circles that the reader has to cross 



in order to access the message (see Section III ) and the number 
of rules to be evaluated to access messages of a given circle. 
In both scenarios we assume a ASN with 100 hierarchically 
organized circles and a user u who wants to access a message 
m. u is member of 50 random circles and T(m) contains 10 
(random) circles ci,...,cio with Vz G [l,10],u M(ci). 
We also define 10 rules composed by 10 random predicates 
for each circle. As shown in Figure [7] the time required for 
u to access the message m is linear to the length of the 
sequence of circles separating u from m. We observed that on 
an average 115 milliseconds were required to access a message 
tagged with the last circle of a sequence of 50 circles. We 
also observed that the number of tags associated with m has a 

8 See |6| for a more formal and complete definition of stateless 



lesser impact on the performances. The main reason is because 
the evaluation of the different possible sequences of circles is 
performed in parallel and, more importantly, distinct sequences 
are merged if during their evaluations common circles are 
found. 

In the second series of experiment on the other hand we 
slightly modified the scenario. We evaluated the time required 
by a user u to access messages contained in a given circle c, 
with u ^ M(c) and <j)(c) = JL (see Section II-B ). As expected, 



the time required is linear with the number of rules associated 
with c. More precisely we observed that on an average were 
required 187 microseconds to evaluate 1000 rules. The results 
are shown in Figure [8] Based on observations, the jitter trend 
in Figure [8] is caused by the memory allocation of the JVM 
and noises from background processes running on the testing 
machine. 
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Fig. 7: Time required to access a message with respect to the 
number of circles in the sequence; the error bar represents the 
10th and the 90th percentiles. 
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Fig. 8: Time required to access a message with respect to the 
number of rules; the error bar represents the 10th and the 90th 
percentiles. 



VI. Related works 

In the current section we briefly discuss some works related 
to the proposed framework. 

Decentralized Social Network. There has been recent 
interests in deploying decentralized online social networking 
(DOSN) as an alternative to the centralized third party services 
such as Facebook in order to avoid big brotherly controls 
and monitoring. Different architectures have been proposed by 
open- source as well as academic communities, which include 



Diaspora^] Appleseecp^] Vis-a-Vis Q, SuperNova | 8 ] among 
others |9|. Traditional anonymous communication and file 
sharing networks such as Freenej^] have also been adapted to 
support friend-to-friend darknet subnetworks. A more detailed 
survey on DOSNs can be found at ifTOl . The main motivation 
of these works is privacy, anonymity and free- speech of 
individuals. The deployment models are predominantly peer- 
to-peer in nature, where most (all) individual participants 
contribute resources to the system and control their individual 
data, and hence the infrastructure provides best effort service, 
and the design focus are towards dealing with system churn, 
fairness & incentives, etc. 

Federated Social Network. Another criticism of central- 
ized social networks like Facebook and Linkedln is that users 
are tied-in, and cannot communicate across networks. Social 
network interoperability has been advocated to address such 
barriers ifTTl . fT2l for users to communicate across social 
networks and achieve portability. In achieving federation of 
such social networks, the main challenge is to specify data 
format and protocol for exchanging information across differ- 
ent platforms - dealing with both technical issues (originating 
from the different existing implementations) and legal and 
commercial issues (e.g., companies are unwilling to expose 
user data to competitors). 

PriSM is instead designed for deployment in workplaces, 
where autonomous social networks (ASN) are deployed and 
managed in a centralized manner on well provisioned infras- 
tructure. It gives its users privacy privileges with respect to 
other fellow users, but not necessarily from the organization 
whose infrastructure the users are using. Instead, it is designed 
to provide the organizations a means to manage their users' 
interactions flexibly and subject to the organizations' security 
and confidentiality needs. The goals of federation are also 
distinct, in that the federation is among multiple ASN in- 
stances with a common set of communication interfaces, but 
the objective is to enable flexible specification and control 
of information across ASNs, as determined by organizational 
business logic and confidentiality needs. Cross-platform fed- 
eration of PriSM ASNs with other social networks will still 
need extrinsic mechanisms 1 121 . 

Commercial alternatives. Oracle Social NetworlFl and 
SalesForc^] are two commercial services providing some 
analogous functionalities by facilitating inter-department and 
inter-organization information exchange using wiki-like plat- 
forms. These services reside in third party cloud infrastruc- 
tures, in contrast to PriSM, which owing to its decentralized 
architecture allows multiple deployment models, including 
third party public cloud as well as fully controlled private 
cloud hosting. Furthermore, PriSM allows customized map- 
ping of organizational hierarchy & workflows and finer grained 
specification of who is entitled to access certain information, 

5 https://ioindiaspora.com/ 



1 1 http ://opensource . appleseedproj ect . org/ 

1 1 https://freenetproject.org/ 

1 2 http ://cloud . oracle . com/my cloud/f ?p=service : social : 

13 http://www.salesforce.com/ 



a feature which is lacking in general purpose services. 

Security and Privacy. OSNs and DOSNs are often crit- 
icized for the currently provided protection mechanisms. To 
overcome such restrictions several works has been done, 
mainly focusing on protecting private and sensible information 
while performing social network analysis (see fT3lL lfT4l ). One 
of the common characteristics of almost all the newly defined 
access control models is that access control is relationship- 
based [15], that is, authorized users are denoted on the basis 
of constraints on the relationships the requester should have 
with other network users and/or the trust level associated 
with a relationship [16]. Following such trend, PriSM natively 
supports an efficient relationship-based security mechanism 
based on relationships specified by means of circles, mimicing 
the security rules of work environments. Such mechanism can 
be easily extended to include more advanced constraints like 
the ones previously presented. 

Access control. With respect to "pure" access control, the 
most widespread family of access control model is RBAC 
(Role-Based Access Control), proposed in ifTTl and in subse- 
quent publications. PriSM provides management of privileges 
as in [17], taking advantage of the role concept with the ob- 
jective to simplify the management of the privileges assigned 
to users. Our approach is also inspired by the works fT8lL 
(2). These works extend the RBAC model such that: the roles 
define the actions that a user may perform while the "team" 
defines the object on which such actions can be performed. 
In PriSM such idea has been further extended using teams 
for refining the privileges associated to roles. Practically, in 
PriSM it is possible for an administrator to create roles that 
are more general than in a pure RBAC model, and therefore 
less in number. The context, defined by the team, will be used 
both to identify the objects on which the user is allowed to 
operate and to slightly change the privileges of the role. As a 
result PriSM provides a way to reduce the increasing number 
of defined roles in order to identify the right set of privileges 
for a given task. This is a common and well known issue in 
systems deploying the RBAC model. To balance that, PriSM 
allows the operational context, the team or in our case the 
subdomain, to grant/revoke privileges when required. An in 
depth discussion of these issues can be found in |fT9l . 

VII. Conclusion and future work 

In this paper we presented PriSM, a framework for 
peer-to-peer interactions among autonomous social networks. 
The PriSM framework is supported by a formal model 
defining relationships and interactions among the different 
users. In particular the framework allows delegated declara- 
tion/administration of (sub-)domains which allow the possibil- 
ity to define inherited privileges and restrictions on individuals 
and groups of users, and provides easy to form communication 
groups for the members to interact among themselves subject 
to the constraints. While PriSM facilitates confidentiality and 
privacy aware communication across autonomous entities, 
thus allowing organizations to retain ownership of data and 



control the flow of information, it does not provide confi- 
dentiality to individual users from the organization to which 
an user belongs. Additional cryptographic techniques would 
be necessary for the same. The modular architecture of our 
implementation will allow such solutions to be plugged in. 

The proposed framework (and the prototype implemen- 
tation) provides a flexible solution for the deployment of 
collaborative network in different application scenarios. These 
include (1) health sector, where different kinds of entities and 
interactions are involved - such as internal communication 
within and across hospitals, supply chain management with 
pharmaceutical companies as well as public relations, out- 
reach and patient support groups, (2) customer relationship 
management and enterprise resource planning for private and 
public companies allowing collaboration for the fulfillment of 
joint operations but still ensuring that the exchanged informa- 
tion abide management policies, (3) educational environment 
complementing existing e-learning tools for better intra/inter- 
institute communication, (4) local/city-level administration, 
etc. We are at the moment engaged in exploratory discussions 
with stake-holders from several of these application scenarios 
to customize and deploy PriSM instances. 

Advances in cloud operating systems (such as Mirag^J 
allow developers to write network applications which can be 
efficiently executed in the cloud environment directly as virtual 
machines. Therefore, we are exploring ways to refine and 
improve the current PriSM implementation for a more portable 
deployment. 

Moreover, we aim to define a user API allowing the 
deploying organizations to create personalized extensions to 
the framework, taking advantage of all the features of the 
communication infrastructure. 

Finally, we also intend to formally define and verify the 
frontier information propagation mechanism, with respect of 
both the policy definition language and the corresponding 
enforcing protocols. 
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